The present invention relates to application servers that use the Java Transaction API (JTA) for global transactions for J2EE applications to ensure data consistency when updates are made to multiple resource managers in a global transaction.
The Java Transaction API (JTA) specification discusses how global transactions may be used in J2EE applications to ensure data consistency when updates are made to multiple resource managers within the context of a global transaction. The JTA specification defines the software interfaces and interactions between the Transaction Manager (TM) and the Resource Manager (RM) as defined in the OpenGroup XA Specification on which the JTA specification is based. In the distributed transaction processing (DTP) model, as defined in the XA specification, an application component accesses one or more resource managers (such as databases or message queuing systems) within a scope of a global transaction that is controlled by the transaction manager. Resource manager updates are associated with a global transaction identifier (Xid) that uniquely identifies the global transaction and includes a branch qualifier component to uniquely identify a resource participant. To provide the Atomicity, Consistency, Isolation, and Durability (ACID) properties, the transaction manager coordinates the resource managers participating in a transaction using the two-phase commit (2PC) protocol. This protocol utilizes and depends on the XA contract between the transaction manager and resource managers to ensure that all changes are either committed or rolled back, that all resource manager state transitions are valid and take place independent of other changes, and that the changes are persistent, even in the event of failure.
FIG. 1 is a diagram that illustrates an exemplary JTA system. The Java application 102 running on an application server 104 can use a transaction manager 106 to interface with the resource managers 108a, 108b and 108c. The resource managers 108a, 108b and 108c can interact with each of the resources for the global transaction. Multiple resources can be included in the global transaction and the JTA system can ensure that either all branches of the transaction are completed or all branches of the transaction are rolled back. In example of FIG. 1, the resources for the transaction include databases 110 and 112 and message queue server 114. Each of the resource managers 108a, 108b and 108c can be registered with the application server 104 as part of the global transaction.
Some transaction Manager implementations assign a consistent Xid branch qualifier for each branch of a transaction that is based on some configuration artifact for a particular resource manager. For instance, the branch qualifier can be derived from the name that was used to register the resource manager with the transaction manager. Because the JTA specification does not specify how a resource manager is registered with a transaction manager, fails to discuss branch qualifier assignment, and provides no API for a resource manager to specify a branch qualifier on enlistment, most transaction manager implementations exhibit similar behavior.
The primary reason for using a consistent branch qualifier is for the case where two or more application components access the same resource manager within a global transaction. If separate branch qualifiers were used for each component, the application may encounter a deadlock within the resource manager since locks are typically not shared across transaction branches.
Some applications require different resource manager contexts in order to specify such attributes as security credentials or isolation level that are pertinent to the application component. The J2EE 1.4 specification discusses such requirements and provides a resource deployment option for un-shareable connections. A resource configured with connection sharing disabled requires that the container provide a new connection for each component requesting a resource manager connection. In order for a transaction manager to assign a single branch qualifier across resource manager connections, the global transaction must be disassociated from all connections before associating another connection with the branch. This requirement may not be possible in environments where the container is unable to intercept application calls to the resource manager.